MAINT: Bump ruff to v0.16 - #234
Conversation
Signed-off-by: Pradyot Ranjan <99216956+pradyotRanjan@users.noreply.github.com>
Signed-off-by: Pradyot Ranjan <99216956+pradyotRanjan@users.noreply.github.com>
Signed-off-by: Pradyot Ranjan <99216956+pradyotRanjan@users.noreply.github.com>
|
Thanks. Does this include both |
|
Has three types of fixes:
|
|
I've opened a PR for safe fixes; after it's merged, I'll open another PR for unsafe fixes. Once we have both merged and main merged with this branch, this PR will be left with the rest of the changes. |
Signed-off-by: Pradyot Ranjan <99216956+pradyotRanjan@users.noreply.github.com>
prady0t
left a comment
prady0t
left a comment
There was a problem hiding this comment.
Some nested if and with statements can be reverted; otherwise, the changes are okay.
| and result_type(x.dtype, y.dtype) != x.dtype | ||
| ): | ||
| assert_raises(TypeError, lambda: getattr(x, _op)(y)) | ||
| assert_raises(TypeError, lambda x=x, _op=_op, y=y: getattr(x, _op)(y)) |
There was a problem hiding this comment.
If we're touching this anyway, then how about
with assert_raises(TypeError):
getattr(x, _op)(y)
There was a problem hiding this comment.
Should we replace all such occurrences with a similar change?
There was a problem hiding this comment.
If you touch them anyway, then yes, I think it'd be nice.
There was a problem hiding this comment.
In the latest commit, I've replaced only in those places where Ruff was complaining.
| for func1 in [ | ||
| lambda s, func=func, a=a: func(a, s), | ||
| lambda s, func=func, a=a: func(s, a), | ||
| ]: |
There was a problem hiding this comment.
Not sure what these are TBH, could you explain?
There was a problem hiding this comment.
That's B023.
Python uses late binding for closures, hence it's worth setting initial value for the variables.
There was a problem hiding this comment.
Let's ignore this if you feel it's confusing.
Signed-off-by: Pradyot Ranjan <99216956+pradyotRanjan@users.noreply.github.com>
There was a problem hiding this comment.
I'm not a fan of littering code with # noqa line noise but that's what it is, no point arguing about it.
The change to using assert_raises as a context manager from lambdas is definitely good.
The self -> _self change in array dunders looks scarier than it is, and the end result is marginally clearer.
All in all, this patch LGTM, thank you @prady0t for seeing it through!
| self, other = self._normalize_two_args(self, other) | ||
| res = self._array.__and__(other._array) | ||
| _self, other = self._normalize_two_args(self, other) | ||
| res = _self._array.__and__(other._array) |
There was a problem hiding this comment.
This pattern (repeated multiple times below) looks usunsual enough, thus I looked a bit more carefully.
The whole _normalize_two_args dance is needed to work around 0D numpy arrays lacking functionality: self._normalize_two_args(self, other) return a pair of -strict arrays, wher each element is either the original argument, or a new -strict array with its internal _array attribute promoted from 0D to 1D. Then, next line, {self, _self}._array.__op__(other._array) does the __op__ with numpy attrbutes, and the next line is return self.__class__._new(res, device=self.device), so we return a new -strict array object.
Either way, we do operations with numpy _array attributes and always return a new -strict array object---the actual operations are done with numpy _array attributes, and this is where it is decided if the actual operation is in-place or not.
Before this patch, the code did potentially mutate self, which was harmless because we always a new object constructed in return self.__class__._new.
This patch only makes the intent clearer by renaming the potentially mutated object.
Conclusion: it is a good change.
| """ | ||
| if not isinstance(shift, int | tuple): | ||
| raise ValueError( | ||
| raise TypeError( |
There was a problem hiding this comment.
Strictly speaking, this is a backwards incompatible change.
That said, TypeError makes more sense, and spot-checking several "real" frameworks shows that a TypeError is more common (exceptions: np.roll(np.eye(3), "oops") raises a ValueError; jnp.roll(jnp.eye(3), None) raise a ValueError too --- these are edge cases though).
The spec does not mandate a specific exception class, thus we can accept the backwards compat break and make change it to a more appropriate exception type, as done here.
2 participants
Closes #228